Network Address Translation (NAT) traversal is a challenge in computer networking that has become a ubiquitous factor that must be taken into consideration when creating new protocols, technologies and services. In current networks, NAT is deployed as a means of security, address-space and network topology abstraction in addition to the originally intended purpose of extending diminishing IPv4 address space.
Because of the variety in application of NAT as a technology, differing requirements has caused great divergence in how a NAT-function is implemented on a given network device. Some implementations first and foremost consider security, while others consider scalability as the primary objective, and there are several flavors in between. Considering these factors when trying to enable an application that must operate transparently whether or not a NAT-device is present in the network transport path or not is required, but extends to a larger challenge when multiple different types of NAT implementations must be considered concurrently and in combination. Such deployments are common in current networks and present a challenge when trying to provide transparent connectivity for an application.
The common types of NAT-implementation are the following:
                a. Endpoint Independent (aka Full Cone), establishes a translation entry between the inside private address and the outside public address and allows any incoming connection from the outside to be established with to the private address        b. Address Dependent (aka Restricted Cone), establishes a translation entry between the inside private address and the outside public address and only allows incoming connections from the outside originating from the address the original flow was using as the destination address.        c. Address and Port Dependent (aka Port-Restricted Cone), establishes a translation entry between the inside private address and the outside public address and only allows incoming connections from the outside originating from the address and upper layer protocol port the original flow was using as the destination address and port.        d. Symmetric, establishes a translation entry between the inside private address and the outside public address where the outside upper layer protocol port is uniquely assigned to every Source Address/Port and Destination Address/Port flow that creates the translation entry in the NAT. Any incoming connection not exactly matching the outside Source Address/Port and Destination Address/Port is disallowed.        
Depending on the specific type of NAT that a given node may be sitting behind or employing locally, incoming connections are treated differently as is evident by the definition of the different types of NAT discussed above. This can create connectivity issues since different protocols deal with NAT-traversal in different ways and may not be able to traverse certain types of NAT without an adaptation of behavior or using a third party node to merge the different legs of a given session-layer connection. In many current implementations, protocols have been adapted to support NAT-traversal and then assume that the NAT will behave in a certain way. If the conditions related to session establishment in such a context are not met then a node may be trying indefinitely, resulting in a poor user experience, where additional information could have allowed for different approach to be taken to ensure that a working communication channel could be established.